For the modern operating system (OS), security is not just a desirable feature, but it is a vital and important component. Security sub-systems of an OS manage user authentication, which includes identification, validation, and authorization. More typically, the OS's security sub-system handles the front-end of such authorization for a network system.
Once the security sub-system has identified the user, the network validates the user and manages her access to available resources. In this typical scenario, the identified/validated users are given access only to a limited set of available resources for which the user is authorized.
Part of the core problem of most security scenarios (including the one described here) is the reliability of the OS's identification of the user. The solution to that problem varies with the needs of those employing the security systems. For example, the reliability of the user's identification is of little importance within the context of a home network. Conversely, the reliability of the user's identification is vital and extraordinarily important in a diplomatic embassy, in the Pentagon, within the R&D department of an international corporation, and the like.
Consequently, a one-size-fits-all approach to a security sub-system is undesirable. Rather, a customized approach is better.
Customizable Security Architecture
FIG. 1 illustrates an example of a customizable architecture and its computing environment. FIG. 1 shows a computer 110 connected to a network server 162 via a connection through a network 160. The computer 110 includes an OS 120, such as Microsoft® Windows® 2000. That OS includes a customizable security sub-system 130.
A customizable security sub-system, such sub-system 130, typically includes a crypto sub-system 140. The crypto sub-system typically includes a set of program module front-ends that allow for the management of cryptographic information. These front-ends are typically implemented as an application program interface (API). Management includes accessing, reading, writing, creating, etc. of cryptographic information (such as the user's public-private key pairs). This cryptographic information is the basis for reliably identifying the user.
The crypto sub-system allows one or more customizable plug-ins. These plug-ins may also be called “cryptographic service providers” (CSPs), “cryptographic solutions,” or “cryptographic program modules.” The CSPs perform the actual cryptographic functionality, such as encryption, decryption, and key management. This cryptographic functionality is a major element in the user-identification process.
As shown in FIG. 1, the crypto sub-system includes CSPs 144–148 which are not part of the original OS. These CSPs may be customized. These custom CSPs allow for the customization of cryptographic identification of users. For custom CSP, the user may be identified by a bio-metric device (such as a retinal scanner); by a smart card reader (such as reader 156); or other the like. Other software (such as 154) or hardware (such as crypto accelerator 158) may be used.
Typically, an OS provides one or more default CSPs, such as default CSP 148 of FIG. 1. The default CSPs are provided with the original OS and they are used unless a customized CSP takes over its functionality. Also, these default CSPs may be useful as a template for the customized CSPs. The default CSP 148 gets the username and password from the user via traditional input mechanisms, such as a keyboard 158.
By allowing the introduction of customized security packages, an OS can better address the needs of a broad set of customers. This is especially desirable for cryptographic modules, since many security-oriented entities, such as governments, require the ability to provide their own, non-public, cryptographic implementations. An OS that is able to meet these needs will provide a customizable security architecture. An example of such an OS is Microsoft® Windows® 2000.
This type of architecture is also valuable where an entity (be it a person or a business, for example) needs a customized security implementation in terms of alternate user-authentication methods or alternate methods of private data storage. For example, smart cards may be used to authenticate access to systems and/or data. Another example includes using bio-metrics to authenticate a user. Examples of bio-metrics include fingerprint-recognition, retinal-recognition, iris-recognition, voice-recognition, and facial recognition. This architecture allows for the security features of an OS to be flexible as authentication technology advances.
Limitations of a Customizable Security Architecture
However, a significant drawback to such an architecture is ensuring the integrity of a customized security plug-in. If the plug-in is unreliable, unstable, and/or does not adhere to a given set of security conformance standards, then the security features of the OS may be easily compromised; thus, casting doubt on the integrity and security of the data and resources protected by the OS.
Furthermore, reports of such security compromises will harm the public perception of the overall security provided the OS despite that fact that the security breaches were caused by a customization rather than the OS itself.
Therefore, there needs to be a mechanism available so that these customized cryptographic solutions may be tested to ensure reliability, stability, and adherence to a given set of security conformance standards.